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(57) ABSTRACT 

The invention provides an improved method and system for 
secure downloading, recovery, and upgrading of data. A 
client device receives information from a server device 
using a reliable software modules stored in permanent 
memory in the client device. The reliable software modules 
perform software and data integrity tests, and locate and 
retrieve data for recovery or upgrade of the client device. 
The client device confirms the trustworthiness of the 
received information device by comparing digital signatures 
or digests for the information it receives with known digital 
certificates in the reliable software module. 
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SECURE DATA DOWNLOADING, 
RECOVERY AND UPGRADING 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is a continuation of application Ser. No. 
09/080,577 filed May 18, 1998, now allowed; which is a 
continuation in part of application Ser No. 08/770,238, filed 
Dec. 20, 1996, in the name of inventors Wei Yen and Steven 
Weinstein, titled "Internet Multiplexer for Broadcast and 
Other Information," now U.S. Pat. No. 5,991,799; which 
claims benefit of Provisional Application Serial No. 60/046, 
749, filed May 16, 1997, in the name of inventors Robert 
Shaw, Christopher Moeller, Clifford Mercer, Mark Law, and 
Luis Valente, titled "Operating System and Memory 
Management," now expired. 

Each of these applications is hereby incorporated by 
reference as if fully set forth herein. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The invention relates to secure downloading, recovery 
and upgrading of data. 

2. Description of Related Art 

Recent developments in networking include client 
devices, which interact with a network to contact one or 
more server devices, and that are disposed for displaying 
information from those server devices. Division of respon- 
sibility among the clients and server allows each client 
device to use relatively fewer resources (such as processing 
power or memory) and therefore to be relatively inexpen- 
sive. Client devices can be manufactured en masse at 
relatively smaller cost and distributed to a large number of 
end users. 

One problem in the known art is that client devices are 
subject to various failures. These can include hardware 
failures, which can damage software used to control the 
client device, and software failures, which can cause the 
client device to operate erroneously. It would therefore be 
advantageous to provide a method and system for recovery 
from memory errors in the client device. Moreover, there 
may be substantial upgrades to software designed for the 
client device developed after the client device has been 
manufactured and delivered to the end user. It would there- 
fore be advantageous to provide a method and system for 
delivering these software upgrades to the client device. 

This problem in the known art is exacerbated by several 
factors. First, as the client device is relatively inexpensive 
and within the complete physical control of the end user, it 
is unknown whether the software available at the client 
device can be trusted. Second, the client device itself cannot 
necessarily trust the data it receives from the server device 
it is coupled to if established over an insecure network, such 
as the internet. Third, the client device has relatively limited 
resources for communicating with the server device; in 
particular, the client device has relatively limited resources 
for rapidly receiving downloaded information from server 
devices. 

Accordingly, it would be desirable to provide an improved 
method and system for secure downloading, recovery, and 
upgrading. This advantage is achieved in an embodiment of 
the invention in which a client device contacts a server 
device using a reliable software module. The reliable soft- 
ware module obtains trustworthy information with which to 
perform software and data integrity tests, and with which to 
locate data for recovery or upgrade of the client device. 
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SUMMARY OF THE INVENTION 

The invention provides an improved method and system 
for secure downloading, recovery, and upgrading. A client 

5 device receives information from a server device using 
reliable software modules stored in permanent memory in 
the client device. The reliable software modules perform 
software and data integrity tests, and locate and retrieve data 
for recovery or upgrade of the client device. The client 

1Q device confirms the trustworthiness of the received infor- 
mation device by comparing digital signatures or digests for 
the information it receives with known digital certificates in 
the reliable software module or received from known trusted 
server devices. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a block diagram of a system for secure data 
downloading and upgrading. 

FIG. 2 shows a process flow diagram for booting a client 
20 device and determining whether there is a need for down- 
loading and upgrading, 

FIG. 3 shows a process flow diagram of a method for 
secure data downloading and upgrading. 

25 DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENT 

In the following description, a preferred embodiment of 
the invention is described with regard to preferred process 

30 steps and data structures. However, those skilled in the art 
would recognize, after perusal of this application, that 
embodiments of the invention may be implemented using 
one or more general purpose processors (or special purpose 
processors adapted to the particular process steps and data 

35 structures) operating under program control, or other special 
purpose circuits, and that implementation of the preferred 
process steps and data structures described herein using such 
equipment would not require undue experimentation or 
further invention. 

40 System Elements 

FIG. 1 shows a block diagram of a preferred embodiment 
of a system for secure data downloading and upgrading. 

A client device 10 has a processor 12 connected to a 
permanent memory 14 and writeable memory 16 by a data 

45 bus 18. Both permanent memory 14 and writeable memory 
16 are non-volatile or other persistent memory. Permanent 
memory 14 is a non-writeable memory, such as a ROM, 
while the writeable memory 16 is a persistent memory, such 
as a NVRAM, flash memory or disk. Client device 10 also 

50 incorporates other memory, such as RAM into which code 
is loaded for execution. 

Stored within permanent memory 14 is boot code 22, 
which controls the initialization boot process for client 
device 10 after a reset or power cycle. Boot code 22 is 

55 further subdivided into host boot code 30 and Navio boot 
code 32. The host boot code 30 is a vendor provided, 
client-resident code that if present initializes the system after 
power-on or a reset and then transfers control to the Navio 
boot code 32. The Navio boot code 32 is the code that is 

60 responsible the selection and execution of either the down- 
loader code 24 or the application code 26. 

The downloader code 24 is stored within permanent 
memory 14 and is a secure set of code which controls the 
connection of client device 10 via I/O port 40 to a commu- 

65 nication channel 50. The downloader code 24 is the only 
copy of code that can be trusted after random or intentional 
corruption as it resides in permanent read-only storage. I/O 
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port 40 is connected to data bus 18, and permits data such At step 130 it is determined whether the application code 

as updater code 70 from a remote server 60 to be down- 26 is intact. If application code 26 is intact, control is 

loaded under the control of downloader 24 via communica- transferred to application code 26 at 140 and client device 10 

lion channel 50 to writeable memory 16 (RAM). Updater proceeds with its normal function. This is the usual result of 

code 70 is code that is stored on the remote server 60 and 5 the boot sequence. If application code 26 is corrupt, control 

downloaded to the client device 10 to upgrade or recover the of client device 10 is transferred to the update downloading 

application code 26. The application code 26 is stored in sequence 150. 

writeable memory 16 and is the application seen by the user Retrieving the Updater 

(Lc. the browser along with the operating system) In order FIG. 2 illustrates the update downloading sequence of the 
to minimize the size of permanent memory 14 and to 1Q datef ?Q ^ rcmote ^ 60 at 15Q nG 3 
maximize flexibility in upgrading application code 26 tor . . , .. , , , r . . 

client device 10, it is desirable for boot code 22 to be as ^ s ' ra f the u P? a down oading sequence in greater 

stream-lined as possible. Additionally, downloader 24 can be dctod. Starting at step 210 where the decision has been made 

compressed in permanent memory 14 to save memory. Later ? load the downloader, the loading process continues at step 

it can be decompressed before being loaded into RAM for 220 Wlth client devicc 10 establishing contact with the 

execution. 15 remote server 60. The client device 10 transmits at step 222 

Communication channel 50 comprises a telephone line, identification information regarding itself, e.g., version 

ISDN line, cable, fiberoptic, or any other data transfer line number, memory size, and requests transmission of an 

connected to a modem or any other network interface device updater code package, a digitally-signed manifest which in 

connected to, or contained within, I/O port 40. Such a some embodiments may contain additional program code for 

connection links client device 10 through a network, either 20 executing the update. 

a private intranet or the public Internet to any of a plurality When the correct updater is located at step 224, a chunk 

of remote servers 60. of updater code 70 will be downloaded to the client device 

Client device 10 includes a forced update feature 20 fr om the remote server 60. Next, client device 10 receives 
which when depressed reboots the client device 10. This me transmitted updater code 70 and checks it at step 226 to 
forced update feature 20 does not need to be a physical ^ determine whether it is valid. In the illustrated embodiment, 
switch. It may for example, consist of a combination of downloader 24 compares a digital signature or digest con- 
switches which when toggled in a specific sequence achieve uined within me datef k with known si nature data 
a reboot and force a download Alternatively, depressing a sayed m downloader code 24 . Because downloa der 24 is 
reset switch for a predetermined extended period of tune, stofed anent me u it fc ^ and 
such as for five seconds, could activate the forced update „ rt , , r , , , . J ! u , . . c ,/ 
feature 20 ^30 and hence a match between the digital signature of the 
Method of Operation updater code package and the stored digital signature vali- 

FIG. 2 shows a process flow diagram for booting client dates ^ identit / of the u P dater - ™* allows client device 10 

device 10 and determining whether there is a need for t0 u P date application code 26 irrespective of the relative 

downloading and upgrading application code 26. security of either communication channel 50 or remote 

Initially, boot code 22, which is further subdivided into its 35 server 60. 
host boot code and Navio boot code portions, takes control Next client device 10 reviews the results of the compari- 
of client device 10. The host boot code 30, a vendor son at step 230. If the signature does not match, the process 
provided, client-resident code initializes the system after returns to step 220, preferably with connection to a different 
power-on or a reset and then transfers control to the Navio remote server 60, and a new updater is received. If the 
boot code 32. After control has been passed to the Navio 40 signatures match, the update process begins with an initial- 
boot code 32 the decision to run the application code 26 or ization process at step 232. The updater contains a table or 
the downloader 24 is made at step 110. The Navio boot code manifest, which logically divides application code 26 into 
performs an integrity check on the application code 26 using smaller code segments, representing portions of or complete 
a verification method such as an MD5 digest because at this logical segments of application code 26. 
part of the process only corruption is being checked as 45 Retrieving the Application Code 

opposed to authenticity. When a valid updater is received the updater is given 

The writeable memory 16 stores two binary values as control of client device 10. It sets the "in update" flag, and 

indicators of system integrity. The first is RunDownloader loads a new update of code segment by segment. The 

which if set causes the downloader 24 to run an upgrade of updater checks each segment of application code 26 for 

the application code 26. The second is TrustData which if 50 corruption by determining whether the contents of a specific 

not set creates the assumption that the data in writeable code segment match a hash or digest, 
memory 16 is corrupt despite any appearance to the contrary. In a preferred embodiment this is implemented by includ- 

This is a validity check to determine whether the writeable ing a manifest or table of secure hashes such as SHA1 in the 

memory 16 which contains information like the local ISP updater 70. Each hash in the table should correspond to an 

phone number and client-id/ password as well as application 55 image of the most recent segment of application code 26. 

code 26 may be trusted. Each hash in the manifest is accompanied by a location 

When either of these two indicators have these assigned identifier, such as an internet URL, for a corresponding 

values, a reset flag 28 is set in the writeable memory and the replacement code segment. This allows different replace- 

Navio boot code 32 forces a system reboot and update at step ment code segments to be stored in separate locations, such 

120. Similarly, the user may also press the forced update 60 as different remote servers 60. This method allows indi- 

feature and force a system reboot and update at step 120. In vidual components of application code 26 to be loaded 

either case once the reboot and update has commenced, the separately. 

downloader 24 initializes and connects to the remote server After the initialization process at step 232, a segment of 

60 and passes the information regarding client-id/password code from application 26 is verified at step 240 using the 

and synchronizes with the remote server 60 at which point 65 hash checklist. As shown at step 242, if that block of code 

the client device 10 may be given a new ISP phone number is valid, client device 10 checks at step 249 to see if there are 

to call. remaining code segments to be verified. If there are more 
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code segments, the process repeats starting at step 240 for 
the next code segment. If there aren't any more code 
segments to check, the application is loaded at step 250 and 
the update is complete. 

If the block of code is invalid at step 242, a substitute 5 
segment of code is downloaded from the corresponding 
URL specified by the updater. The downloaded code seg- 
ment may be encrypted to provide additional security or 
compressed for transmission to speed download time. After 
the code segment is downloaded at step 244 and any 10 
required decryption or decompression is performed, the new 
code segment is checked against its respective hash at step 
246 and if it matches at step 247 it is then written to 
write able memory 16 at step 248 to replace the corrupted 
segment of application code 26. 15 
Launching the Application Code 

When a hash does not correspond to an image of the most 
recent chunk of application code 26, the updater 70 down- 
loads a file that is designated in the table. At step 246 a check 
is made to see if there are any more code segments of 20 
application code 26 to be checked. After all of the code 
segments of application code 26 have been checked and 
validated at steps 242 through 247 and any necessary 
replacement code segments written to memory at step 248, 
the application code 26 is completely loaded and ready to 25 
execute at step 250. 

In a preferred embodiment each file downloaded by the 
updater 70 is compressed to minimize bandwidth and speed 
transmission through communication channel 50. In 
addition, each segment of code downloaded preferably has 30 
a default size of no greater than 64 kilobytes to correspond 
with the size of a sector of flash memory. Additionally, the 
segments of code to be downloaded should be in ascending 
order of memory address, non-overlapping and they should 
not cross a flash sector boundary. 35 

Once a given segment of code is downloaded and 
decompressed, it is authenticated and validated by using the 
same hash that was used to check the segment of application 
code 26 which it is replacing and which originally failed the 
hash check. If the hash matches that in the table of updater 40 
70 then the downloaded segment of code is authentic and is 
allowed to overwrite its respective segment of application 
code 26 in writeable memory 16. This is a means of linking 
security from the digital signature of the updater to the 
downloaded segments of code because the authentication 45 
happens in the process of downloading. Thus, the digital 
signature is on the downloaded datastream as well as the 
updater image in memory. 

In a preferred embodiment the table of secure hashes, 
SHA1 or other equivalents thereof, has a dual purpose. 50 
Because the table of secure hashes can check the digest of 
segments of application code from the updater for validity 
without checking the whole code segment, a means of 
compression is achieved in addition to a validity check. For 
example, a twenty-byte long SHA1 hash can be used to 55 
verify a large code segment like a 128 -kilobyte segment by 
skipping the segments that are valid. If only a few segments 
of code need to be replaced, the savings in transmission time 
and bandwidth will be substantial. This time savings is 
important not only to the user of client device 10, but also 60 
to the remote server 60 when a large number of client 
devices 10 need to be updated, such as when a new version 
of a segment of application code 26 is released or when the 
number of client devices in service is very large. 

Using the process described above, the present invention 65 
ensures that a client device 10 can restore a corrupted 
application code 26 using minimal program code stored in 
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permanent memory 14. Because the validation process 
occurs each time client device 10 is initialized, the integrity 
of application code 26 can be maintained on an ongoing 
basis. Further, because of the use of digitally signed hashes 
in the updater, secure transmission of only those segments of 
application code 26 which need to be updated can be 
achieved using unsecured remote servers 60 and communi- 
cation channels 50. 
Alternative Embodiments 

Although preferred embodiments are disclosed herein, 
many variations are possible which remain within the 
concept, scope, and spirit of the invention, and these varia- 
tions would become clear to those skilled in the art after 
perusal of this application. 

What is claimed is: 

1. A method of updating application code on a client 
device from a remote server, said method comprising: 

performing a boot sequence on said client device, said 
boot sequence including (a) verifying the validity of 
application software contained in a writeable memory, 

(b) automatically retrieving without user intervention 
from the remote server through a communication chan- 
nel update data for identifying invalid code segments, 

(c) automatically retrieving without user intervention 
from the remote server through said communication 
channel replacement code for replacement of said 
invalid code segments, and comparing validity status 
data within said update data for identifying invalid code 
segments such that only invalid code segments need be 
replaced whereby a compression of data transmission is 
effected. 

2. The method of claim 1, wherein said boot sequence 
further comprises checking for a forced update signal and 
initiating retrieval of said update data in response to said 
forced update signal. 

3. The method of claim 1, wherein said boot sequence 
farther comprises checking a forced update flag and initiat- 
ing retrieval of said update data in response to said forced 
update flag. 

4. The method of claim 1, wherein comparing said valid- 
ity status data within said update data for identifying invalid 
code segments to be replaced is performed automatically 
without user intervention. 

5. A system for updating application code from a remote 
server, said system comprising 

a client device including a writeable memory; 

an interface between said client device and a communi- 
cation channel to said remote server; 

software code stored in said writeable memory to perform 
a boot sequence on said client device, said boot 
sequence including (a) determining whether to update 
a software application stored in said writeable memory, 
and terminating the boot sequence if no update is 
necessary, (b) automatically retrieving without user 
intervention from said remote server over said com- 
munication channel update data for identifying invalid 
code segments, (c) automatically retrieving without 
user intervention from said remote server over said 
communication channel replacement code for replace- 
ment of said invalid code segments, (d) comparing 
validity status data within said update data for identi- 
fying invalid code segments such that only invalid code 
segments need be replaced whereby a compression of 
data transmission is effected, and (e) comparing 
authentication data within said update data with authen- 
tication data stored in said memory for authenticating 
said update data. 
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6. The system of claim 5, wherein step (a) further com- code segments to be replaced is performed automatically 
prises checking for a forced update signal and initiating an without user intervention. 

update in response to said forced update signal. 20. A memory storing information including instructions, 

7. The system of claim 5, wherein step (a) further com- the instructions executable by a processor to update appli- 
prises checking a forced update flag in said writeable 5 cation code on a client device from a remote server over a 
memory and initiating an update in response to said forced communication channel, the instructions comprising: 
update flag. performing a boot sequence under control of boot code 

8. The system of claim 5, wherein said boot sequence stored in permanent memory in said client device, said 
further includes: (f) downloading and authenticating said boot sequence including (a) determining whether to 
replacement code from servers specified by location data 10 update a software application stored in writeable non- 
within said update data upon successful authentication of volatile memory, and terminating the boot sequence if 
said update data, and (g) writing said replacement code into no update is necessary, (b) automatically retrieving 
said writeable memory. without user intervention from said remote server over 

9. The system of claim 8, wherein step (f) comprises sa jd communication channel update data for identi re- 
determining from said validity status data in said update data 15 i n g invalid code segments, (c) automatically retrieving 
which code segments of said software application require without user intervention from said remote server over 
updating and downloading only those software code seg- sa jd communication channel replacement code for 
ments requiring updating. replacement of said invalid code segments, (d) com- 

10. The system of claim 8, wherein said validity status paring validity status data within said update data for 
data comprises hash codes corresponding to discrete logical 20 identifying invalid code segments such that only 
segments of code within said software application. invalid code segments need be replaced whereby a 

11. The system of claim 10, wherein said location data compression of data transmission is effected, and (e) 
comprises internet addresses corresponding to said discrete comparing authentication data within said update data 
logical segments of code. with authentication data stored in said permanent 

12. The system of claim 8, wherein said replacement code 25 memory for authenticating said update data. 

is encrypted and step (f) further comprises decrypting said 21. The memory of claim 20, wherein step (a) further 

replacement code. comprises checking for a forced update signal and initiating 

13. The system of claim 8, wherein said replacement code an update in response to said forced update signal. 

is compressed and step (f) further comprises decompressing 22. The memory of claim 20, wherein step (a) further 

said replacement code. 30 comprises checking a forced update flag in said writeable 

14. The system of claim 5, wherein said authentication memory and initiating an update in response to said forced 
data comprises a digital signature. update flag. 

15. The system of claim 5, wherein comparing said 23. The memory of claim 20, wherein said boot sequence 
validity status data within said update data for identifying further includes: (f) downloading and authenticating said 
invalid code segments to be replaced is performed automati- 35 replacement code from servers specified by location data 
cally without user intervention. within said update data upon successful authentication of 

16. A memory storing information including instructions, sa id update data, and (g) writing said replacement code into 
the instructions executable by a processor to update appli- sa id writeable memory. 

cation code on a client device from a remote server, the 24. The memory of claim 23, wherein step (f) comprises 

instructions comprising 40 determining from said validity status data in said update data 

performing a boot sequence on said client device, said which code segments of said software application require 

boot sequence including (a) verifying the validity of updating and downloading only those software code seg- 

application software contained in said memory, (b) ments requiring updating. 

automatically retrieving without user intervention from 25. The memory of claim 23, wherein said validity status 

the remote server through a communication channel 45 data comprises hash codes corresponding to discrete logical 

update data for identifying invalid code segments, (c) segments of code within said software application, 

automatically retrieving without user intervention from 26. The memory of claim 25, wherein said location data 

the remote server through said communication channel comprises internet addresses corresponding to said discrete 

replacement code for replacement of said invalid code logical units of code. 

segments, and (d) comparing validity status data within 50 27. The memory of claim 23, wherein said replacement 

said update data for identifying invalid code segments code is encrypted and step (f) further comprises decrypting 

such that only invalid code segments need be replaced said replacement code, 

whereby a compression of data transmission is effected, 28. The memory of claim 23, wherein said replacement 

17. The memory of claim 16, wherein step (a) further code is compressed and step (f) further comprises decom- 
comprises checking for a forced update signal and initiating 55 pressing said replacement code. 

retrieval of said update data in response to said forced update 29. The memory of claim 20, wherein said authentication 

signal. data comprises a digital signature. 

18. The memory of claim 16, wherein step (a) further 30. The memory of claim 20, wherein comparing, said 
comprises checking a forced update flag and initiating validity status data within said update data for identifying 
retrieval of said update data in response to said forced update 60 invalid code segments to be replaced is performed automati- 
flag. cally without user intervention. 

19. The memory of claim 16, wherein comparing said 

validity status within said update data for identifying invalid ***** 
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